Overview
The redundant License Manager feature is useful for your customers who have a large network installation and want to maintain License Manager backup. This consists of more than one redundant License Manager providing failover. When the main License Manager goes down, the remaining License Managers provide high availability without causing any downtime or loss of licenses for the existing or new users (as long as licenses are available).
NOTE Starting RMS 9.8.1, an industry-standard secret-key authenticated encryption is used to secure RMS License Manager communication, including the inter-License Manager communication. Make sure that the same version of a License Manager is installed in all the machines in a pool.
The Redundant License Manager Concepts
In this topic, we have listed the terms and concepts related to the redundant License Managers.
| Terms | Details |
|---|---|
| License Manager Pool |
A group of Sentinel RMS License Managers hosting the same license. Given below are some notes related to the License Managers in a pool: >The License Manager computers in a pool need not be in the same subnet—these can be in geographically separate locations, in subnets connected via WAN, Internet, or dial-up connections. >A License Manager can exist only in one pool. >A pool can have License Managers running on different operating systems. However, the same version of License Manager must be installed in all the computers in a pool. |
| The Redundant License Manager Configuration File (lservrlf) | The redundant License Manager configuration file (by default named lservrlf) contains information regarding the redundant License Managers in a pool, including their names and/or IP addresses*, the order in which the License Managers cater to the license requests and the license string. This file is created and managed at your customer's site using the redundant license file tools—rlftool or WRlfTool. Otherwise, you can create a customized option\utility created using the redundant license configuration file API functions provided in the lsrlf library. |
| Primary License Manager | This refers to the first License Manager added in the redundant configuration file. |
| Follower License Managers | It refers to all the License Managers, other than the primary License Manager, specified in the redundant configuration file. |
| Leader |
It refers to the License Manager having the highest priority among the other running License Managers at any given time. When the primary License Manager goes down, the follower License Manager having the highest precedence as defined in the configuration file lservrlf, becomes the leader and serve the clients request. NOTE In this chapter, we have considered the primary License Manager as a leader. The license tokens always remain with the leader License Manager and are not distributed among other License Managers in the pool. The leader synchronizes communication between the License Managers in the pool. The leader also makes sure that all the License Managers in the pool are using the same version of the redundant license file. If this file is changed on one of the License Manager computers, after one of the License Managers is stopped and restarted, the leader detects the change in the file and automatically updates the rest of the License Manager computers to the newer version. |
| Majority Rule |
While creating a redundant license code you may require that its redundant License Managers use majority rule. This dictates that a majority (over half) of the redundant License Managers must be up and running for a request for that active license to be serviced. For example, if you have defined five redundant License Managers and majority rule is in effect, at least three of them must be up and running or a request for that license will fail. If majority rule is not in effect, your customer could set up the redundant License Managers and then separate them on different networks. Each redundant License Manager, not being able to see any of the others, would then allow your customer to double, triple, quadruple, etc., the total license count without purchasing that many license tokens. So, although you can turn majority rule off, you incur a huge security risk in doing so. If majority rule is in effect for a particular license code and the majority of redundant license License Managers go down, requests for licenses for that feature/version are no longer serviced until the majority of License Managers are up and running again. However, requests for non-redundant licenses or redundant license codes not using majority rule will continue to be serviced. We recommend that you always enable majority rule while generating licenses. By default, the majority rule is enabled for supporting three or more redundant License Managers in both WlscGen and lscgen. |
* It is possible to create redundant License Manager pool consisting of IPv6-based systems. However, the redundant License Manager configuration file can store either IPv6 or IPv4 addresses i.e. a redundant License Manager pool consisting of both the License Managers (both IPv4 and IPv6) is not supported. So, if the pool consists of IPv6 systems, only IPv6-based clients can communicate in the setup. The similar behavior is true for IPv4 setup.
Note that redundant License Manager pool is not supported when Link Local addresses of the License Managers are used.